Determining targeted incentives based on consumer transaction history

ABSTRACT

Systems, apparatus, and methods for determining incentives based on consumer history. When, how, and to whom incentives are sent can be determined. For example, an incentive can be sent to a consumer to encourage a transaction at a time when the particular consumer is predisposed to initiate the transaction. Also, an incentive for a transaction can be sent to a consumer when that transaction has a high likelihood of leading to other transactions. An incentive can also be sent after a consumer initiates a transaction that is known to not have many subsequent transaction correlated to it.

CROSS-REFERENCES TO RELATED APPLICATIONS

This present application is a continuation of U.S. application Ser. No.12/773,765, entitled “DETERMINING TARGETED INCENTIVES BASED ON CONSUMERTRANSACTION HISTORY” which claims priority from and is a non provisionalapplication of U.S. Provisional Application No. 61/175,381, entitled“SYSTEMS AND METHODS FOR DETERMINING AUTHORIZATION, RISK SCORES, ANDPREDICTION OF TRANSACTIONS” filed May 4, 2009, the entire contents ofwhich are herein incorporated by reference for all purposes.

This application is related to commonly owned and concurrently filedU.S. patent application Ser. No. 12/773,763, filed on May 4, 2010,entitled “PRE-AUTHORIZATION OF A TRANSACTION USING PREDICTIVE MODELING,”by Faith et al., U.S. patent application Ser. No. 12/773,766, filed onMay 4, 2010, entitled “DEMOGRAPHIC ANALYSIS USING TIME-BASED CONSUMERTRANSACTION HISTORIES,” by Faith et al., U.S. patent application Ser.No. 12/773,767, filed May 4, 2010, entitled “TRANSACTION AUTHORIZATIONUSING TIME-DEPENDENT TRANSACTION PATTERNS,” by Faith et al., and U.S.patent application Ser. No. 12/773,770, filed May 4, 2010“FREQUENCY-BASED TRANSACTION PREDICTION AND PROCESSING” by Faith et al.,the entire contents of which are herein incorporated by reference forall purposes.

BACKGROUND

The present application is generally related to tracking and processingconsumer transactions, and more specifically to using a history ofconsumer activity in determining incentives to send to consumers.

Manufacturer, retailers, or other sellers of products (e.g. goods andservices) services spend a lot of time and money trying to devise waysto get a consumer to buy their products. For example, companiesadvertise, send incentives for discounts, offer rewards, and otherincentives to get consumers initiate a transaction for the products.However, these efforts are typically provided to the public at large, orat least a relatively large group of consumers, which can result in ahigh cost and a low return. Also, the timing of any efforts aretypically based on when the seller wants to send an incentive, with theseller having no insight as to a beneficial time or manner to send anincentive.

Therefore, it is desirable to provide improved methods of sendingincentives to a consumer, which can increase a return rate on theincentive and reduce overall cost.

BRIEF SUMMARY

Embodiments provide systems, apparatus, and methods for determiningincentives based on consumer history. Certain embodiments can help todetermine when, how, and to whom incentives should be sent. For example,some embodiments can determine when a particular consumer is likely toinitiate a transaction, and send an incentive to the consumer toencourage the transaction to actually occur. In this manner, theincentive can be sent at a time that is likely to have an effect, andnot when the consumer is unlikely to perform the transaction, therebyincreasing the rate of return. Other embodiments can send an incentivefor a transaction type to a consumer when that transaction type has ahigh likelihood of leading to other transactions (called a gateway). Yetother embodiments send an incentive after a consumer initiates atransaction (called a dead end) that is known to not have manysubsequent transaction correlated to it.

According to one embodiment, a method of providing an incentive to aconsumer is provided. Data corresponding to previous transactions, whichcan be associated with the consumer and/or similar consumer, arereceived. A computing system determines a pattern of the previoustransactions. Based on the determined pattern of the previoustransactions, a likelihood for the future transaction is determined at aplurality of times. A time window when the consumer is likely toinitiate a future transaction is predicted using the likelihoods at theplurality of times. An incentive associated with the future transactionis sent to the consumer such that the consumer receives the incentive ata time correlated with the predicted time window.

According to another embodiment, a computer system determines alikelihood of any transaction occurring after a first type oftransaction initiated by the consumer. An incentive for a futuretransaction of the first type is sent to the consumer based on thelikelihood being greater than a threshold.

According to yet another embodiment, a computer system determines anamount of transactions that are correlated to a first transaction typeand that occur after the first transaction type. After a transaction ofthe first transaction type occurs, an incentive for any transaction issent based on the amount being below a threshold.

Other embodiments of the invention are directed to systems, computerapparatuses, portable consumer devices, and computer readable mediaassociated with methods described herein.

As used herein, an “incentive” can be any data or information sent to aconsumer to encourage a transaction. For example, a coupon can be sentto a consumer as an incentive since the consumer can obtain a bettertransaction price. As another example, an advertisement can be sent to aconsumer to encourage a transaction by making the consumer aware of aproduct or service. Other example of incentives can include rewards formaking a transaction and preferential treatment when making thetransaction.

A better understanding of the nature and advantages of the presentinvention may be gained with reference to the following detaileddescription and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of a system according to an embodiment ofthe invention.

FIG. 2 shows a plot of a transaction history or other events of aconsumer as analyzed according to embodiments of the present invention.

FIG. 3 is a flowchart of a method for providing an incentive to aconsumer according to an embodiment of the present invention.

FIG. 4 is a plot of a number of transactions at certain elapsed timesbetween a final transaction (with key KF) and an initial event (with keyKI) of a correlated key pair according to embodiments of the presentinvention.

FIG. 5A shows a table for use in determining a periodic probabilityfunction that approximates a pattern of transactions according to anembodiment of the present invention.

FIG. 5B shows a plot for use in determining a number of columns(buckets) of time or frequency to separate the previous transactionsaccording to an embodiment of the present invention.

FIG. 6 a flowchart of a method for determining a likelihood of atransaction and a time window of its occurrence according to embodimentsof the present invention.

FIG. 7 is a flowchart of one method for tracking an impedance of atransaction to future transactions by updating values using a backwardflow of events according to embodiments of the present invention.

FIG. 8 is a flowchart of a second method for tracking an impedance of atransaction to future transactions by updating values using a forwardflow of events according to embodiments of the present invention.

FIG. 9 is a flowchart of a method for providing an incentive to aconsumer to encourage a gateway transaction according to embodiments ofthe present invention.

FIG. 10 is a flowchart of a method 900 for providing an incentive to aconsumer to encourage transactions after a dead end according toembodiments of the present invention.

FIG. 11 shows a block diagram of an example computer system usable withsystems and methods according to embodiments of the present invention.

DETAILED DESCRIPTION

Incentives (e.g. coupons) are often sent to large groups and are nottailored to specific individuals who are likely to act on the incentive,and thus resources can be wasted. For example, many of the people maynever buy certain products, and thus incentives should not be expendedon such individuals. Moreover, even if a consumer is inclined to act onthe incentive, the incentive might be sent at an inopportune time.Furthermore, if a consumer is inundated or receives incentives at randomtimes, the consumer might get irritated. Accordingly, embodimentsprovide systems, apparatus, and methods for determining incentives basedon consumer history. For example, embodiments can help to determinewhen, how, and to whom incentives should be sent.

Some embodiments can determine when a particular consumer is likely toinitiate a transaction, and send an incentive to the consumer toencourage the transaction to actually occur. In this manner, theincentive can be sent at a time that is likely to have an effect, andnot when the consumer is unlikely to perform the transaction, therebyincreasing the rate of return. Other embodiments can send an incentivefor a transaction type to a consumer when that transaction type has ahigh likelihood of leading to other transactions (called a gateway). Yetother embodiments send an incentive after a consumer initiates atransaction (called a dead end) that is known to not have manysubsequent transactions correlated to it.

I. System Overview

FIG. 1 shows an exemplary system 20 according to an embodiment of theinvention. Other systems according to other embodiments of the inventionmay include more or less components than are shown in FIG. 1.

The system 20 shown in FIG. 1 includes a merchant 22 and an acquirer 24associated with the merchant 22. In a typical payment transaction, aconsumer 30 may purchase goods or services at the merchant 22 using aportable consumer device 32. The merchant 22 could be a physical brickand mortar merchant or an e-merchant. The acquirer 24 can communicatewith an issuer 28 via a payment processing network 26. The merchant 22could alternatively be connected directly to the payment processingnetwork 26. The consumer may interact with the payment processingnetwork 26 and the merchant through an access device 34.

As used herein, an “acquirer” is typically a business entity, e.g., acommercial bank that has a business relationship with a particularmerchant or an ATM. An “issuer” is typically a business entity (e.g., abank) which issues a portable consumer device such as a credit or debitcard to a consumer. Some entities can perform both issuer and acquirerfunctions. Embodiments of the invention encompass such single entityissuer-acquirers.

The consumer 30 may be an individual, or an organization such as abusiness that is capable of purchasing goods or services. In otherembodiments, the consumer 30 may simply be a person who wants to conductsome other type of transaction such as a money transfer transaction or atransaction at an ATM.

The portable consumer device 32 may be in any suitable form. Forexample, suitable portable consumer devices can be hand-held and compactso that they can fit into a consumer's wallet and/or pocket (e.g.,pocket-sized). They may include smart cards, ordinary credit or debitcards (with a magnetic strip and without a microprocessor), keychaindevices (such as the Speedpass™ commercially available from Exxon-MobilCorp.), etc. Other examples of portable consumer devices includecellular phones, personal digital assistants (PDAs), pagers, paymentcards, security cards, access cards, smart media, transponders, and thelike. The portable consumer devices can also be debit devices (e.g., adebit card), credit devices (e.g., a credit card), or stored valuedevices (e.g., a stored value card).

The merchant 22 may also have, or may receive communications from, anaccess device 34 that can interact with the portable consumer device 32.The access devices according to embodiments of the invention can be inany suitable form. Examples of access devices include point of sale(POS) devices, cellular phones, PDAs, personal computers (PCs), tabletPCs, handheld specialized readers, set-top boxes, electronic cashregisters (ECRs), automated teller machines (ATMs), virtual cashregisters (VCRs), kiosks, security systems, access systems, and thelike.

If the access device 34 is a point of sale terminal, any suitable pointof sale terminal may be used including card readers. The card readersmay include any suitable contact or contactless mode of operation. Forexample, exemplary card readers can include RF (radio frequency)antennas, magnetic stripe readers, etc. to interact with the portableconsumer devices 32.

The access device 34 may also be a wireless phone. In one embodiment,the portable consumer device 32 and the access device are the samedevice. For example, a consumer may use a wireless to phone to selectitems to buy through a browser.

When the access device 34 is a personal computer, the interaction of theportable consumer devices 32 may be achieved via the consumer 30 oranother person entering the credit card information into an application(e.g. a browser) that was opened to purchase goods or services and thatconnects to a server of the merchant, e.g. through a web site. In oneembodiment, the personal computer may be at a checkout stand of a retailstore of the merchant, and the application may already be connected tothe merchant server.

The portable consumer device 32 may further include a contactlesselement, which is typically implemented in the form of a semiconductorchip (or other data storage element) with an associated wirelesstransfer (e.g., data transmission) element, such as an antenna.Contactless element is associated with (e.g., embedded within) portableconsumer device 32 and data or control instructions transmitted via acellular network may be applied to contactless element by means of acontactless element interface (not shown). The contactless elementinterface functions to permit the exchange of data and/or controlinstructions between the mobile device circuitry (and hence the cellularnetwork) and an optional contactless element.

The portable consumer device 32 may also include a processor (e.g., amicroprocessor) for processing the functions of the portable consumerdevice 32 and a display to allow a consumer to see phone numbers andother information and messages.

If the portable consumer device is in the form of a debit, credit, orsmartcard, the portable consumer device may also optionally havefeatures such as magnetic strips. Such devices can operate in either acontact or contactless mode.

Referring again to FIG. 1, the payment processing network 26 may includedata processing subsystems, networks, and operations used to support anddeliver authorization services, exception file services, and clearingand settlement services. An exemplary payment processing network mayinclude VisaNet™. Payment processing networks such as VisaNet™ are ableto process credit card transactions, debit card transactions, and othertypes of commercial transactions. VisaNet™, in particular, includes aVIP system (Visa Integrated Payments system) which processesauthorization requests and a Base II system which performs clearing andsettlement services.

The payment processing network 26 may include a server computer. Aserver computer is typically a powerful computer or cluster ofcomputers. For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aWeb server. The payment processing network 26 may use any suitable wiredor wireless network, including the Internet.

As shown in FIG. 1, the payment processing network 26 may comprise aserver 26 a, which may be in communication with a transaction historydatabase 26 b. In various embodiments, a transaction analyzer 26 c candetermine patterns in transactions stored in transaction historydatabase 26 b to determine certain actions, such as authorizing atransaction or sending an incentive. In one embodiment, an incentivesystem 27 is coupled with or part of payment processing network 26 andcan be used to determine an incentive based on determined transactionpatterns. Each of these apparatus can be in communication with eachother. In one embodiment, all or parts of transaction analyzer 26 cand/or transaction history database 26 b may be part of or sharecircuitry with server 26 a.

The issuer 28 may be a bank or other organization that may have anaccount associated with the consumer 30. The issuer 28 may operate aserver which may be in communication with the payment processing network26.

Embodiments of the invention are not limited to the above-describedembodiments. For example, although separate functional blocks are shownfor an issuer, payment processing network, and acquirer, some entitiesperform all or any suitable combination of these functions and may beincluded in embodiments of invention. Additional components may also beincluded in embodiments of the invention.

II. Identifying Patterns

Consumer activity can include transactions, among other things.Knowledge of a pattern of transactions of a consumer can allowidentification of opportunities to incentivize continuing or newbehavior of a consumer, as well as provide other advantages. However,the identification of a pattern can be difficult given the enormousamount of data, some of which might exhibit patterns and some of whichmay not.

As used herein, the term “pattern” refers broadly to a behavior of anyset of events (e.g. transactions) that have a likelihood of repeating.In one aspect, the likelihood can be greater than a random set ofevents, e.g., events that are uncorrelated. The likelihood can beexpressed as a probability (e.g. as a percentage or ratio), a rank (e.g.with numbers or organized words), or other suitable values orcharacters. One type of pattern is a frequency-based pattern in whichthe events repeats with one or more frequencies, which may bepredefined. To define a pattern, a reference frame may be used. Invarious embodiments, the reference frame may be or include an elapsedtime since a last event (e.g. of a type correlated to the currentevent), since a beginning of a fixed time period, such as day, week,month, year, . . . (which is an example of a starting event), before anend of a fixed time period, or before occurrence of a scheduled event(an example of an ending event). Another event can be certain actions bythe consumer, such as traveling to a specific geographic location orbrowsing a certain address location on the Internet.

FIG. 2 shows a plot 200 of a transaction history or other events of aconsumer as analyzed according to embodiments. Plot 200 shows times atwhich each of a plurality of previous transactions 210 have occurred. Asshown, time is an absolute time (e.g. date and time) or an elapsed timesince an initial event 203. Herein, the term “time” can refer to eitheror both a date and a time of a particular day. These previoustransactions 210, which occur before an end time 205, can be analyzed todetermine a pattern 220, which can be a function that approximates whenthe transactions are likely to occur. As an example, an identifiedpattern can be used to predict a likelihood of a next transaction, e.g.transaction 230.

As shown, the previous transactions do not always correspond withpattern 220. For example, the third peak of pattern 220 is missing atransaction. This example provides one instance where a likelihood of atransaction is determined, but an incentive to have the transactioncontinue might be desired.

The identification of a pattern can have many difficulties. If theprevious transactions 210 include all of the transactions of a consumerand exhibit only one pattern, then the identification of a pattern maybe relatively easy. However, if only certain types of transactions for aconsumer show a pattern, then the identification can be more difficult.Some embodiments can use keys (K1, K2, . . . ) to facilitate theanalysis of certain types of transactions, where a key can correspond toa type of transaction. A key can also allow identification oftransactions as being relevant for a current task (e.g. the key beingassociated with a transaction to be incentivized).

Adding to the complexity can be whether the path to a particulartransaction has an impact on the pattern, e.g., a pattern that existsonly when certain transactions precede or follow a transaction.Embodiments can store transaction data associated with a specific orderof keys (e.g. K1, K3). In this manner, the data for that specific ordercan be analyzed to determine the pattern. The order of keys also allowsthe further identification of relevant transactions.

All of this complexity can be further compounded in instances where acertain path (sequence of two or more transactions) can have more thanone pattern. Embodiments can use certain functional forms to helpidentify different patterns. In some embodiments, a combination ofperiodic functions are used, e.g., e^(−iwt), where w is a frequency of apattern. In one embodiment, the frequencies are pre-selected therebyallowing an efficient determination of the patterns. Further, thefrequencies can be identified by an associated wavelength, or wavelengthrange. Counters can be used for each wavelength range, thereby allowinga pattern to be very quickly identified by analyzing the values of thecounters.

III. Sending an Incentive when a Transaction is Likely

Incentives (such as coupons) can be an effective way of increasing alikelihood that a consumer buys a product. However, incentives arenormally sent at times that are not related to when a consumer mightactually be looking to buy a product. If a consumer were to receive aincentive just before he/she is going to make a purchase, the likelihoodof the use of that incentive is much greater. However, if the consumerreceives an incentive when the transaction is not likely (e.g. an itemis not needed), then the consumer's use of the incentive (i.e. an actualtransaction) can be low.

FIG. 3 is a flowchart of a method 300 for providing an incentive to aconsumer according to embodiments. In one embodiment, previoustransactions (e.g. 210) are used to determine when, how, and whatincentives are to be provided. In one implementation, transactionswithin a specific time period are analyzed, e.g., last year or alltransactions before an end time. The transactions can also be filteredbased on certain criteria, such that only certain types of transactionsare analyzed. The transaction history can include valid and fraudulenttransactions. All or parts of method 300 or other methods herein can beperformed by a computer system that can include all or parts of network26; such a system can include disparate subsystems that can exchangedata, for example, via a network, by reading and writing to a samememory, or via portable memory devices that are transferred from onesubsystem to another.

In step 310, data associated with transactions previously performed(e.g. by the consumer or other consumers) is received. For example, thedata in the transaction history database 26(b) can be received at atransaction analyzer 26(c) of system 20 in FIG. 1, which includes aprocessor that may be configured with software. Each transaction canhave any number of pieces of data associated with it. For example, thedata may include categories of an account number, amount of thetransaction, a time and date, type or name of product or serviceinvolved in the transaction, merchant name or code (mcc), industry code,terminal field (whether a card is swiped), and geographic location(country, zip code, . . . ). In one embodiment, a merchant could be awhole chain or a particular store of a chain. In some embodiments, thetransaction data can also include video and/or audio data, e.g., toidentify a person or a behavior of a person. The transaction data can bedifferent for each transaction, including the account number. Forexample, the consumer can be identified with the account number andother account numbers of the consumer can be included in the analysis ofthe behavior of the consumer.

This data can be used to identify a particular type of transaction. Inone embodiment, the data for a transaction is parsed to identify one ormore keys, which are used as identifiers for a particular transaction.In various embodiments, a key can includes parts of the transaction dataand/or data derived from the transaction data. A key could also becomposed of results from an analysis of a transaction, e.g., whether thetransaction is a card-present transaction or a card-not-presenttransaction could be determined from the transaction data and includedin the key. In one embodiment, a mapping module can perform the mappingof the transaction data to one or more keys.

A key can be composed of multiple pieces of data (referred to herein asa key element). A longer key has more key elements and may be a moreselective identifier of a type of transactions. Each transaction can beassociated with different keys, each with a different scope ofspecificity for characterizing the transaction.

In step 320, transactions are optionally correlated with othertransactions and events. In this manner, different transaction patternscan be identified for different types of transactions. Other events(e.g. start or end of a day, week, etc.) can be correlated totransactions as well. An event can also be a movement of the consumerfrom one state to another (e.g. from an at-home state to an on-vacationstate). Different events can also be identified with keys. Herein,examples are used to described how keys are used to identify transactiontypes, but other suitable methods can be used.

In one embodiment, pairs of correlated keys (e.g. a key pair <KI:KF>)are determined based on whether transactions associated with an initialkey (KI) are correlated with transactions with a final a final key (KF).A first (initial) event can be correlated with a later (final)transaction. The initial key and the final key may be the same ordifferent from each other. For example, a transaction at one merchantmay be correlated to a later purchase at another merchant, which mightoccur if the merchants are near to each other. In one embodiment, agroup of more than two keys could be correlated together, e.g. a groupof three keys can be correlated.

Two transactions can be correlated in multiple ways depending on howmany keys are associated with each transaction. Thus, two transactionscan contribute to more than one key pair, when the transactions areassociated with multiple keys. For example, if an initial transaction isassociated with two keys and the final transaction is also associatedwith two keys, then there could be four resulting key pairs. Also, atransaction may be correlated to another transaction only via certainkeys.

In step 330, one or more patterns of when the previous transactionsoccur are determined with a computer system, e.g., the transactionanalyzer 26(c), which can be a subsystem or one apparatus. The patternscan convey the likelihood of a transaction as a function of time. Forexample, pattern 220 conveys that transactions are likely when thefunction has a higher value.

In one embodiment, pairs of correlated transactions (or other events)are used to determine a pattern, e.g., as times of final transactionsrelated to initial events. The times can be stored as an absolute timeand/or date for each transaction (e.g. in chronological order) ororganized as elapsed times for correlated events of certain key pairs.The elapsed time may be the time between a transaction with K1 and thenext transaction with K2 for the correlated <K1:K2> pair. Other data canbe stored as well, e.g. data not included in the keys, such as an amountof the transaction. The elapsed time can effectively equal an absolutetime if the initial event is the beginning of a time period.

In some embodiments, the time information is stored (e.g. in transactionhistory database 26 b) associated with the corresponding key pair. Forexample, a key pair identifier (e.g. a unique ID number) can beassociated with the stored time information. As examples of anassociation, a key pair identifier could point to the time information,the time information could be stored in a same row as the key pairidentifier, and the key pair identifier could be stored associated withthe pointer.

In other embodiments, the time information for the key pair <K1:K2> canbe stored in a database table that can be accessed with a querycontaining K1, K2, or the combination (potentially in the order ofK1:K2). For example, a search for K1 and/or K2 can provide theassociated identifiers. In one embodiment, a hash of each key of a pairis also associated with the key pair identifier, so that information foreach key can be indexed and found separately. For example, hashes of K1and K2 can be stored in a lookup table so the key pair identifiers (andthus the key pair information) can be easily found.

In one aspect, storing time information in association with certain keypairs can allow the time information for specific types of transactionsto be easily accessed. Also, such organization can provide easieranalysis of the data to identify patterns for specific key pairs. Theoccurrences of the transaction can then be analyzed (e.g. Fourieranalysis or other functional analysis) to identify a pattern of thetimes and dates of these transactions.

In step 340, a time window when the consumer is likely to initiate afuture transaction is predicted based on the determined patterns. Thetime window may be specified in any number of ways. For example, thetime window may specify a start date/time and an end date/time. In someembodiments, the patterns of the previous transactions are used todetermine a likelihood for the future transaction at a plurality oftimes. The time window can be identified by analyzing the consumer'stransaction pattern to determine times with a desirable level oflikelihood for a transaction to occur. In such embodiments, the timewindow can be obtained with greater accuracy since a plurality of timesare used. Aldo, one can be more likely to identify a time window havinga desirable level of likelihood since multiple times are analyzed.

In one embodiment, the likelihood is for any transaction by theconsumer, and thus the entire transaction history can be used. Inanother embodiment, the likelihood is for a particular transaction. Whena particular transaction is being investigated, the relevant pattern canbe found by querying a database using the key(s) of the particulartransaction.

A pattern can have certain indicia that can be analyzed to determinelikelihoods at different times. In various embodiments, the indicia maybe a number of transactions in a time range, the probability at a givenpoint in time (e.g., as calculated from a value of the pattern functionat the point in time), or other measure related to likelihood. In oneaspect, the time window can be measured relative to a time when theanalysis is being done (e.g. at the end time 205).

In one embodiment, the time window is determined from when the patternshows a likelihood above a threshold value. In another embodiment, thedesired time window may be when the transaction is likely, but toolikely (e.g. medium likely), because if there is a very high likelihoodthen an incentive may not be needed. Also, one may not want thelikelihood to be too low as then the incentive may have a small chanceof being used. In these and other embodiments, the duration of the timewindow can be variable (i.e. no predetermined) duration. For instance,the duration of the time window can be based on the likelihood values(e.g. the times when the likelihood rises above and falls below thethreshold.

In some embodiments, the indicia of the relevant pattern can be inputinto a modeling function as part of the determination of the timewindow. In various implementations, the modeling function can be anoptimization function (e.g. a neural network) or can be a decision tree(e.g. composed of IF THEN logic that compares the indicia to one or morecutoff values). In one embodiment, an optimization function can betrained on previous transactions, and thus can determine how much atransaction (e.g. at various times) fits the pattern of a particularentity (e.g. a consumer or merchant). In another embodiment, the numberof keys associated with the transaction relates to the number of inputsinto the modeling function. The relationship is not necessarilyone-to-one as similar keys (e.g. ones of a same category) may becombined (e.g. same key elements, but just different values), but theremay be a correspondence between the number of different types of keysand the number of inputs.

The time window for a first consumer can also be based on thetransaction activity of other consumers, or in place of the transactionactivity of the first consumer. For example, the incentive could also besent at a particular time that a transaction for such a product ispredicted for a similar consumer, and thus can be likely for the firstconsumer. Such a strategy may be employed when data for the firstconsumer is limited and does not yet show the particular pattern.

In an embodiment using other consumers, the first consumer can bedetermined to be similar to an affinity group (group of similarconsumers). In one aspect, consumers can be similar to an affinity groupwith varying degrees of similarity (e.g. by percentage of similarity).In one embodiment, a likely time window can correspond to when acorresponding affinity group has a high likelihood for the transactionat a specific time, but the consumer does not show any pattern for thetransaction or has a relatively low likelihood at the specific time (butpotentially high at other times). In another embodiment, theoptimization algorithm mentioned above can also be trained usingprevious patterns from multiple entities.

Referring back to method 300, in step 350, a type of incentive toencourage a transaction is determined. The incentive may, for example,be for a specific merchant, a specific type of merchant (e.g. using anMCC code), or a specific product (or service) at any merchant. Thecategories for the incentive can be determined from the specificpatterns where a transaction was found to be likely. In one embodiment,incentives can also be determined based on inventory levels, which alsocan be predicted from patterns of affinity groups. In anotherembodiment, the incentive is valid only during the predicted timewindow.

In various embodiments, the incentive can also be based on how likely atransaction is, whether patterns from other consumers are used, and howclosely the keys for the pattern match the keys for the transactionbeing encouraged. For example, knowing the likelihood can influence howmuch of a discount to be sent in a coupon. If a consumer is only mediumlikely to make the transaction during a time window then more incentivecan be required relative to if the consumer is highly likely. In oneimplementation, relative values of likelihood between differenttransaction patterns can be determined by normalizing across alltransactions, or across certain patterns.

In one embodiment, the payment processing network 26 may haverelationship deals with specific companies, advertisers, ormanufacturers for sending incentives. The payment processing network 26may then retrieve an incentive from an incentive system 27 that iscoupled with or part of the payment processing network 26. The incentivesystem 27 may be a simple repository of incentives or information onspecific incentives. In one embodiment, the payment processing network26 can identify specific properties of a incentive (e.g. merchant,merchant type, product, . . . ) and then query the incentive system 27for an incentive. The incentive system 27 may be tasked with keeping anup to date listing of incentives that may be used. The incentive system27 may also retrieve incentives from servers associated with particularmerchants, manufactures, advertisers, or other companies.

In some embodiments, the incentive can be for a different product thanwhat has previously been purchased. In one embodiment, a pattern may beobserved for transactions at a specific merchant, but the transactionsdo not always or generally include a certain product at the merchant. Anincentive for that product could be sent at a time corresponding to thenext transaction. For example, a consumer can be encouraged to buy a newproduct (e.g. music) from a coffee shop, when the consumer is nextpredicted to visit the coffee shop to buy coffee. An incentive couldalso be sent for a store near the coffee shop.

In other embodiments, an incentive can be used for the same product toreward loyalty (e.g. so the consumer continues coming back at thepredicted time). In various embodiments, an incentive can be for reducedprice, layaway offer, offer of financing, and warranty. The type ofincentive can also be determined based on when the incentive is sent,which can be correlated to the time window. For example, a layaway planmight be provided if the time window is near the holidays.

In step 360, an incentive for the transaction is sent to the consumersuch that the consumer receives the incentive at a time correlated withthe predicted time window. For example, the incentive can be sent justbefore the time window or at the beginning of the time window. The exactamount of lead time may depend on the length (duration) of the timewindow and when the prediction is made. For example, if the time windowis very short and/or the time window starts soon after the predictioncalculation is performed, then the incentive can be sent just before thetime window. Such a scenario can be typical when the predictioncalculation is performed in response to receiving an initial transactionthat is typically followed soon after by the final transaction of acorrelated pair. In another example, the incentive could be sent to theconsumer during the time window, which may be done in instances when thetime window is long. In yet another embodiment, the incentive can besent at a predetermined time (e.g. 10 minutes, 1 hour, one day, or oneweek) before the start of the time window.

The incentive may be transmitted in any number of suitable ways. In oneembodiment, an electronic message may be sent to the consumer or adevice (e.g. a phone or computer) associated with the consumer. Examplesof electronic messages include a message sent to a consumer's phone(e.g., SMS or MMS by including a coupon code) and an e-mail, which canhave a code and may be printed. In another embodiment, the incentive isa physical object that is delivered by mail or other delivery service.Thus, an object (such as an envelope, package, or mailer of just theincentive itself) including the incentive may be sent to a physicaladdress (e.g. home or business) associated with the consumer. In oneembodiment, the incentive is sent to a particular address (physical orelectronic); and if a transaction using the incentive occurs for aconsumer associated with that address (e.g. product is order from orshipped to that address), then the use of the incentive can be used toauthenticate the consumer.

IV. Analysis of a Pattern

If a pattern of when transactions occur is known, then the pattern canbe used to determine what times to send an incentive and what type ofincentive to send. For example, if a pattern (e.g. a pattern oftransactions associated with specific keys) for one or more previousmonths is known, embodiments can use this pattern to determine a patternfor a future month (e.g. for same month next year or for a next month).Incentives can then be sent encourage existing patterns to continue orcreate new ones based on a likelihood for other similar consumers (e.g.an affinity group). The patterns can be analyzed in numerous ways, andFIG. 4 describes some embodiments.

FIG. 4 is a plot 400 of a number of transactions at certain elapsedtimes between a final transaction (with key KF) and an initial event(with key KI) of a correlated key pair according to embodiments. Plot400 can be considered as a histogram. The X axis is elapsed time betweena final transaction and a correlated initial event. Any unit of time maybe employed, such as minutes, hours, days, weeks, and even years. The Yaxis is proportional to a number of transactions. Each bar 410corresponds to the number of transactions at an elapsed time. Each bar410 can increase over time as new transactions are received, where a newtransaction would have an elapsed time relative to a correlated initialevent. Note that more than one transaction-event pair can have the sameelapsed time.

In one embodiment, the X axis can have discrete times. For example, onlytransactions for each day may be tracked. Thus, if the initial event wasthe start of a month, then the number of discrete time periods wouldhave a maximum of 31 days. In such an embodiment, elapsed time valueswithin a certain range can all contribute to a same parameter, and bars410 may be considered as counters. For example, if the discrete timeswere by day, any two transactions that have an elapsed time of 12 dayssince a correlated KI event would both cause the same counter to beincreased. In one embodiment, these counters are the time informationthat is stored as mentioned above. In some implementations, the timeranges do not all have the same length. For example, the time rangescloser to zero can have a smaller length (e.g. just a few minutes) thanthe time ranges further from zero (e.g. days or months).

A pattern 420 can be discerned from the elapsed times. As shown, pattern420 has a higher value at elapsed times where more transactions haveoccurred. In one embodiment, pattern 420 could simply be the countersthemselves. However, in cases where the time intervals are not discreteor have a small range, bars 410 might have zero or low value at timesthat happen to lie between many transactions. In these cases, certainembodiments can account for transactions at a specific time as well astransactions at times that are close. For example, as shown, a functionrepresenting pattern 420 begins curving up and plateaus near the cluster460 of transactions to form a peak 430. In one embodiment, each timepoint of the function can have a value of a moving average of the numberof transaction within a time period before and after (or just one or theother) the time point. In other embodiments, function can be determinedfrom interpolation or other fitting method (e.g., a fit to periodicfunctions) performed on the counters.

Indicia of the pattern 420, e.g., the function values, can be analyzedto determine when a transaction is likely. In one implementation, peaksof the pattern 420 are identified as corresponding to times when atransaction is likely, and a time window is determined from indicia ofthe peaks. In one embodiment, a width of the function at specific valuesor times may then be used as the time window. For example, a time window(e.g. a two day or 1.5 day period) of when transactions often occur maybe determined (e.g. as may be done in 340).

The time window may be determined in any number of ways and potentiallywith varied criteria. In one embodiment, a full width at half maximummay be used, such as the width of peak 430. In another embodiment, thewindow (e.g., 440) above a threshold value 450 is used, or just part ofthis window, e.g., starting at the time where pattern 420 is above thethreshold and ending at the top (or other part) of peak 430. In yetanother embodiment, the time window may have a predetermined widthcentered or otherwise placed (e.g. starting or ending) around a maximumor other value above a threshold.

In embodiments using a threshold, the value of the pattern function maybe required to be above the threshold value before a transaction isconsidered likely enough to occur to send an incentive to a consumer. Asmentioned above, multiple threshold levels can be used, with the variouslevels potentially being used to determine when, how, and whatincentives to use. The use of thresholds encompass using the exactlikelihood values, which can be equivalent to using many thresholdlevels. The modeling function mentioned above may be used to perform anyof these determinations.

In one embodiment, a threshold determination could be whether a counterhas a high enough value (absolute or relative to one or more othercounter). In another embodiment, a threshold level can be relative (e.g.normalized) compared to a total number of transactions. A normalizationor determination of a threshold can be performed by adjusting the leveldepending on the low values of likelihood of a pattern, e.g., a peak totrough height could be used. In one aspect, the troughs may be offset tozero.

Storing time information that includes a number of transaction atcertain elapsed times, one can not only handle paths (such as initialkey to final key), but one can also easily identify multiple patterns.Each peak can correspond to a different pattern. For example, each peakcan correspond to a different frequency of occurrence for a transactionassociated with the final key relative to an event (e.g. a transaction)associated with the initial key. In one embodiment, the time informationfor the elapsed times can be stored by storing a time of when bothevents occur. In another embodiment, time information can store theelapsed time as one value. In yet another embodiment, the time of oneevent might implicitly include the time of the initial event (e.g. whenthe first event is beginning of a month or other fixed time period).

From FIG. 4, one can identify one predominant pattern (peak 430) with along wavelength (short frequency), which does not occur very often, andthree minor peaks with higher frequencies. However, the determination ofa pattern might still take significant computational effort if thepattern can have any functional form.

V. Use of Periodic Functions and Counters

Some embodiments use certain functional forms to help identify differentpatterns. As mentioned above, periodic functions can be used, e.g.,e^(iwt), where w is a frequency of the pattern. For example, each bar(counter) 410 of FIG. 4 can correspond to a different frequency. Thetotal probability V of a K2 transaction occurring at a time t after a K1transaction can be considered as proportional to

${\sum\limits_{W}{C_{w}e^{iwt}}},$where C_(w) corresponds to the counter value at the frequency w and wruns over all of the frequencies. C_(w) can be considered a coefficientof the periodic function e^(iwt) at a particular frequency. Thus,conceptually, a probability can be calculated directly from the aboveformula.

In one embodiment, the frequencies are pre-selected thereby allowing anefficient determination of the patterns. Further, the frequencies can beidentified only by the associated wavelength, or wavelength range. Notethat in certain embodiments, the use of e^(iwt) is simply a tool and theactual value of the function is not determined.

FIG. 5A shows a table 500 that stores time information for a key pair<KI:KF> according to embodiments of the present invention. The table 500stores information for elapsed times between transactions associatedwith the particular key pair. Table 500 can also store amountinformation for the transactions. Table 500 can be viewed as a tabularform of plot 400 along with all the possible variations for differentembodiments described for plot 400.

In one embodiment, each column 510 corresponds to a different timerange. The time range may correspond to ranges mentioned above withreference to FIG. 4. As shown table 500 has 6 time ranges, but anynumber of time ranges may be used. The time ranges can be considered tocorrespond to different functions that approximate the transactionpatterns of a consumer or other entity. For example, each time range cancorrespond to or be considered a different frequency w for e^(iwt).

In some embodiments, table 500 only has one row. In other embodiments,the rows of table 500 correspond to different dollar amounts (or dollaramount ranges). Thus, each time range may have subgroups for set rangesof amounts (e.g. dollar amounts). The organization is similar to amatrix, where a row or a column can be viewed as a group or subgroup.Although five amount ranges are shown, table 500 can have any number ofdollar amounts. In some embodiments, there is only one row. i.e. whendollar amounts are not differentiated. Note that the convention of rowand column is used for ease of illustration, but either time or amountcould be used for either row or column (each an example of an axis).Also, the data for a table can be stored in any manner, e.g. as a singlearray or a two-dimensional array.

The values for the matrix elements 520 correspond to a number of KFtransactions that have elapsed times relative to a KI event (e.g. atransaction) that fall within the time range of a particular column 510.In one embodiment, each newly received K2 transaction can cause a box(element) 520 of the table (matrix) 500 to be increased. The value ofthe matrix element (an example of a likelihood value) can be incrementedby one for each transaction, or another integer or non-integer value.The value can also be a complex number, as described below. In anotherembodiment, a table can be required to have a certain total of allvalues, average of the values, minimum value in any matrix element, orother measure of the values in the table. Such a requirement can ensurethat enough data has been received to provide an accurate pattern.

The values of the matrix elements can be used to determine the patternfor the key pair <KI:KF>, e.g. as part of step 330 of method 300. Forexample, matrix elements with high values relative to the other matrixelements can indicate a pattern of transactions in the correspondingtime range, which can correspond to a particular frequency w. In anotherembodiment, one could view each matrix element in isolation to determinewhether a transaction is likely. For example, if a matrix elementexceeds a threshold value, it may be determined that a transaction islikely to occur in that time range. The threshold can be determined invarious ways, for example, as a function of a sum of all of the matrixelements, or equivalently can be fixed with the matrix elements beingnormalized before a comparison to a threshold. Thus, step 330 can beaccomplished easier based on how the time information is stored.

As mentioned above, the time ranges can all be of the same length (e.g.24 hours) or be of varying lengths. In one embodiment, the first columnis of very short time length, the second column is of longer timelength, and so on. In this manner, more detail is obtained for shortwavelengths while still allowing data to be stored for long wavelengthswithout exhausting storage capacity. In another embodiment, dollaramount ranges are progressively structured in a similar manner as thetime ranges can be. In one implementation, the dollar amount range canbe used to track the likelihood of transactions having certain dollaramounts.

FIG. 5B shows a plot 510 for use in determining the time ranges fortable 500 according to an embodiment of the present invention. The Xaxis corresponds to the column numbers. The Y axis corresponds to thetime of a particular column in minutes. For example, the first columnincludes times between the first data point at time domain zero and thedata point at time domain 1. Due to the large scale of the Y axis, thesecond data point appears to be at zero, but is simply quite smallrelative to the maximum value.

The wavelength λ of a pattern corresponds to the time range of a column.For embodiments, using time relative to another transaction, then the λis the time between transactions. In one embodiment, 16 time domains(ranges) are selected as follows: λ₀ is under 1 minute, λ₁ is between 1minute and 2.7 minutes, λ₂ is between 2.7 minutes and 7.4 minutes, λ₃ isbetween 7.4 minutes and 20 minutes, and λ₁₅ is over 1.2 million minutes.

The amount values can also be used to determine patterns fortransactions of certain dollar amounts. If the amount is not of concern,then the values in a column can be summed to get a total value for acertain time range. The amounts can also be incorporated into themathematical concept introduced above. For example, in mathematicalnotation, a value function can be defined as

${V = {\sum\limits_{W}{C_{w}{Ae}^{iwt}}}},$where A is an amount of a transaction.

When a transaction is received, the amount and corresponding elapsedtime for a particular key pair can be used to determine a correspondingmatrix element for the key pair table. The values in the matrix elementscan be normalized across one table and across multiple tables. Forexample, a value can be divided by a sum for all the values of aparticular key pair table. Also, a sum can be calculated for all valuesacross multiple tables, and the values for each table divided by thissum. As part of a normalization, the value for a matrix element may bedecreased when some of the data used to determine the value becomes tooold. For example, for a time range that includes short time intervals,counts from transactions that have occurred more than a year ago may bedropped as being out of data since short timeframe patterns can changequickly.

In various embodiments, tables for different key pairs can havedifferent time ranges and/or amount ranges. If such differences dooccur, the differences can be accounted when a summing operation isperformed. In one embodiment, the values in the matrix elements can besmoothed to account for values in nearby matrix elements, e.g., in asimilar fashion as pattern 420.

In another embodiment, tables for different consumers can be compared todetermine affinity groups. For example, tables with matching or similarkey pairs can be subtracted (lower value more similarity) or multiplied(higher value more similarity). The closer the tables are, the moresimilarity (e.g. as a percentage) the consumers are, where non-matchingtables can be used for normalization. In one example, one set of tablescan correspond to the affinity group, and the calculation can be used todetermine whether a person is within the affinity group.

In other embodiments, specific amount ranges or time ranges can besuppressed. For example, if only certain types of patterns (e.g. onlycertain frequencies) are desired to be analyzed, then one can suppressthe data for the other frequencies. In one embodiment, the suppressionis performed with a mask matrix that has zeros in frequency columnsand/or amount rows to be suppressed. Thus, one can just multiply thematrices to obtain the desired data. The amount ranges can be similarlysuppressed. When suppressing certain frequencies, these mask matricescan act similarly to a high pass, low pass, or notch filters. Forexample, if one wanted a coupon to be good only for 7 days, and it takes1 day to create the coupon, the desired time window is any time rangethat includes those 6 days. Accordingly, the time information fortransactions outside the time window can be suppressed as not being ofinterest.

Regarding the creation and updating of such tables, after an event (e.g.a consumer transaction) is received, embodiments can determine whichtracked key pairs have finals keys that match with the keys resultingfrom the transaction. As a transaction can be associated with many keysand key pairs, a transaction may cause many tables to have a matrixelement updated. For example, the transaction may cause different tablesfor a specific consumer to be updated. The updates could be for onetable for all transactions by that consumer (an example of a generaltable), and more specific tables for particular zip codes, merchants,and other key elements. The transaction can also cause updates of tablesfor the particular merchant where the transaction occurred.

As there are different tables that can be updated, each with a differentinitial key, the time range (and thus the matrix element) that isupdated may be different for each table. For example, when elapsed timeis used, the last transaction for each table may be at a differentelapsed time since the different initial transactions. The transactionamount would typically be the same, thus the exact row for the matrixelement to be increased can be the same, as long as the tables have thesame amount ranges. But the column (i.e. time) could be different foreach table.

Regarding which time column to update, there can also be more than onecolumn updated for a particular table. For example, a K2 transaction mayhave different time patterns relative to K1 transactions (i.e., <K1:K2>pair). Accordingly, when a K2 transaction is received, elapsed timesfrom the last two, three, or more K1 transactions could be used toupdate the table.

In a similar manner, one key pair table could be <*:K2>, which includescorrelations from a plurality of initial keys to the K2 key in the sametable. Effectively, this table could equal the sum of all tables whereK2 is the final key for a particular consumer or other entity. However,if the individual key pairs are not significant enough, the <*:K2> tablemay be the only table that is tracked. Tables of the type <K1:*> couldalso be tracked.

VI. Using Tables to Determine Time Window

To predict a likelihood of a future event (e.g. a transaction), someembodiments can obtain the relevant key pair tables for the entity (e.g.a consumer) and then analyze these tables. Which tables are obtained andhow they are analyzed depends on exactly what events are trying to bepredicted, i.e. the question being answered.

FIG. 6 is a flowchart of a method 600 for determining a likelihood of atransaction and a time window of a likely occurrence according toembodiments. Method 600 can be performed by any one, plurality, orcombination of computer apparatus described herein, and componentsthereof.

In step 610, data for one or more recent and/or upcoming events isreceived. In one embodiment, the event data (e.g. transaction data) isassociated with one entity, e.g., a particular consumer or affinitygroup. For recent events, whether an event is “recent” can be relativeto other events. For example, if an event does not occur often, a recentevent (e.g. a last event of that type) can still occur a long time agoin absolute terms. For an upcoming event, the event has not occurredyet, but can be known to occur. For example, the start of a month (orother time period) has a known time of occurrence. As another example, ascheduled event (such as a sporting event or concert) can be used. Datafor these scheduled events can be obtained before they occur due to thenature of these events.

In step 620, the event data is used to map each event to one or morekeys KI. In some embodiments, the mapped keys KI are specifically keysthat are being tracked for an entity. In step 630, tables of patternsthat have an initial key of KI are obtained, thereby providing <KI:tables relevant to the received event data. In one embodiment, amatching and retrieval function identifies the relevant tables usingmethods described herein. The matching and retrieval function can alsomatch tables that do not have the exact same key, but similar keys. Asimilar key can be a broader version (e.g. first 3 digits of a zip code)of a more specific key (e.g. 5 digit zip code). Examples of when suchalignment would be performed include: when a specific key for a currenttransaction is received, but only a broader version of that key is beingtracked; and when two entities are being compared and different keypairs are tracked. In embodiments where an event is an upcoming event,the upcoming event can be a final event (or effectively the time rangescan be negative with the upcoming event being an initial event), wheretransactions before the ending event are analyzed.

In step 640, the <KI: tables having matrix elements with sufficientlyhigh counts are identified to determine KF events that are likely tooccur. In one embodiment, to determine whether a matrix element has asufficiently high count, one or more absolute or relative thresholdnumbers can be used. A relative threshold (e.g. a percentage) could bedetermined using a total number of counts for a table or group oftables. In another embodiment, all tables (i.e. not just ones with amatching KI for initial key) could be analyzed to find matrix elementswith high counts, thereby eliminating steps 610 to 630. However, usingrecent or upcoming events can provide greater timeliness for any result,or action to be performed based on a result. The identified KF eventsalong with the specific time ranges for the matrix elements with thehigh counts can then be analyzed.

In step 650, other matrix elements not previously identified areobtained for each likely KF event. For example, a KF event can becorrelated to more initial keys than just the ones identified in step620. These previously unanalyzed tables can also have high counts forcertain matrix elements involving a KF event. The KF event can be usedas a filter to identify unanalyzed tables, from which other high-countmatrix elements can be obtained. Thus, this step can be used to obtain amore accurate likelihood for a specific KF event. Obtaining these otherhigh-count matrix elements may not be needed, e.g., if KI is startingevent, such as a beginning of a week, month, etc. In this case, sinceother tables might include the same data points, these other tablescould just include redundant information.

Also, low count matrix elements for KF events already determined to belikely can be important if high accuracy is desired. For example, as thetimeframes of the different :KF> tables can be different (due todifferent KI events), matrix elements having relatively low counts cancorrespond to the same timeframe as a high-count matrix element. Thus,the number of counts for a likely time range can be revised.

In this manner, high probability KF events can be determined based on afew recent or upcoming KI events, and then a full analysis of :KF>tables can be performed, as opposed to randomly selecting KF events todetermine when they might be likely to occur. A KF event could be chosenfor analysis, but a selected KF event might not be highly likely.However, if one were interested in a specific KF event, then it may bedesirable to start method 600 at step 650.

In step 660, the matrix elements (e.g., just from step 640 or also fromstep 650) are combined to obtain a probability distribution vs. time fora :KF> event, which is correlated to many <KI: events. In oneembodiment, each of the matrix elements for the KF event are combinedfrom a portion or all of the <KI:KF> tables, where KI runs over theinitial events that are correlated to the KF event. This combination canaccount for the fact that the different KI events occur at differenttimes, and thus the time ranges for each table can be different (e.g.offset).

In one implementation, the earliest or latest KI event can beidentified, and offsets for the time ranges of the other tables can bedetermined. The corresponding matrix elements can then be added usingthe offsets. If a time range of a matrix element of one table onlypartially overlaps an offset time range of another table, then thecombination can be broken up into more time ranges with proportionalcontributions from each previous rime range. For example, if two timeranges overlap, then three time sections can result. The overlap sectioncan receive contributions (i.e. a percentage of the counts) from the twomatrix elements, with the amount of contribution proportional to theamount of overlap in time for the respective time ranges.

To determine a time range of high likelihood, a probability distributioncan be created from the resulting time ranges X after the combinationand the counts Y for each time range. The resulting time ranges X withthe respective counts Y can be analyzed as a function Y=F(X), which cancorrespond to pattern 420 of FIG. 4. The Y values can be normalized sothat the counts for time ranges of different lengths are accounted. TheY values can also be normalized based on the dollar amount of atransaction.

In step 670, a total likelihood for a KF event (e.g. across multipleinitial events) is calculated. In one embodiment, the likelihood can befor a specific time window or for the KF event occurring at any futuretime. A specific time window may correspond to a predetermined timerange of a matrix element, or be another time range that results from anoverlap of multiple time ranges. For example, if two matrix elementsoverlap in time (e.g. because the KI events occur at different times),then the time window may have the range of the overlap time. In anotherembodiment, the likelihood for a KF transaction can also be for one ormore specific amounts of the transaction, which can be selected bymultiplying with a mask matrix.

To determine a time range of high likelihood, the probability function Fcan be analyzed. For example, the function F can be analyzed with anumerical routine to identify a maximum or regions having values above athreshold (or potentially within a range, e.g., using multiplethresholds). To identify maximum regions, techniques such as finitedifference, interpolation, finite element, or other suitable methods,can be used to obtain first and second derivatives of F. These derivatescan then be used in an optimization algorithm for finding a maximum.Global optimization methods can also be used, such as simulatedannealing.

In addition to finding a time window when an event is likely, a totalprobability over a specific time period can be obtained. In oneembodiment, the function F can be integrated (e.g. sum counters for timeranges) over the desired time range. In effect, to obtain a probabilitythat an event will occur within a prescribed time period, one canintegrate contributions over all of the relevant key pairs during thetime period. As an example with one key pair, a probability that someonewill perform a certain event (e.g. a transaction) once they are visitingSan Francisco can be obtained by integrating the key pair <SF:KF> overall of the desired time periods. In one aspect, time periods of greaterthan one month may not be relevant if a person never stays in SanFrancisco for that long (which could be identified from a location of aperson's phone or by locations of transactions). One could alsodetermine a probability for a transaction to occur in November in asimilar way.

As an alternative to all of the above steps, one can select a particularevent and a particular time, which can be used to select the relevantpatterns from which the corresponding matrix element can be analyzed. Ifthe tables indicate a desirable likelihood (e.g. relative to thresholdvalues), then an incentive can be sent for that consumer. Multipleconsumers can be analyzed in this process. In this manner, a seller candetermine an incentive to send for a particular transaction and thensimply find the consumers that would more likely respond.

In one embodiment, the relevant patterns from which the correspondingmatrix element are selected by creating a set of key pair tables with 1or other non-zero values in the appropriate matrix elements. Thesetables are then multiplied by the saved tables (i.e. known patterns) toobtain the likelihood, effectively filtering out the desired values.Besides a particular time, a time window can also be specified, whichmay cause more than one matrix element in a table to have a non-zerovalue. In this case, the non-zero values can be based on a level ofoverlap of the time window with the corresponding time ranges of thematrix elements.

Referring back to method 600, in step 680, a course of action can bedetermined based on likelihood and/or time window. Various exampleactions and determinations are now described. If a likelihood is low,then no action can be taken. If a likelihood is high, then a time windowfor that high likelihood can be determined. If the time window startssoon, an action that can be performed soon (e.g. sending a coupon viae-mail or text message) can be initiated. Whereas if the time windowdoes not start for an extended period of time, an action that takeslonger (e.g. creating a mailer) can be performed.

Also, once an event is found to be likely, further analysis can beperformed regarding an incentive. For example, a cost of an action, suchas the cost of sending an incentive, can be determined as part of acost-benefit analysis. For example, the cost of a paper brochure,internet ad, or text message may impact if an incentive is sent, whichtype of incentive is sent, and how an incentive is sent. In oneembodiment, the cost of an action can include a possible loss due tofraud, which can be calculated by comparing a recent transaction patternof a consumer to patterns known to be fraudulent (e.g. by multiplyingtables of a consumer against tables of a fraud entity). In anotherembodiment, a profit of an event can be determined, e.g., the profitfrom a transaction resulting from an incentive. If the profit is high,then a higher cost and lower likelihood can be tolerated. A profit canalso include situations where inventory levels are high, and thus theproduct needs to be sold quickly.

In one embodiment, calculations for the prediction of an event can berun in real time (e.g. within several hours after an event or series ofevents occur). In another embodiment, the calculations can be run asbatch jobs that are run periodically, e.g., daily, weekly or monthly.For example, a calculation can run monthly to determine who is likely tobuy a house, and then a coupon for art, furniture, etc. can be sent tothat person. In various embodiments, prediction of major purchases cangenerally be run in larger batches, whereas prediction of smallpurchases can be run in real-time (e.g., in reaction to a specifictransaction).

In some embodiments, ending events also can be used similarly to predictwhat may happen before the event. Since the occurrence of an endingevent can be known ahead of time (e.g. scheduled for a particular time),the correlated initial events can still be predicted. For example,consumer activity prior to a schedule sporting event can be determined,which may be done, e.g., using tables having negative time ranges withthe ending event as an initial key or with positive time ranges with theending event as a final key. An incentive can be sent for a transactionoccurring before the sporting event (or other ending event), asdescribed herein.

VII. Impedance (Likelihood of Another Transaction)

Besides being able to predict when a particular transaction will occur,embodiments can also predict if another transaction is going to occurafter a current or a predicted transaction, which is referred to asimpedance. In some embodiments, such information can be tracked by usingcomplex numbers for the matrix elements of the final event, with theimaginary part corresponding to the impedance. In other embodiments, theimpedance can be tracked simply using another number for a matrixelement or using another table.

In such embodiments, the imaginary part of a matrix element cancorrespond to an impedance that measures how likely it is that anothertransaction will occur. The likelihood can specifically correspond to afuture transaction being correlated to the current transaction havingthe time range and dollar amount of the matrix element. The real valueof a matrix element can correspond to the probability that the KF eventwill occur, and the imaginary value can relate to the probability thatanother event will be correlated to the KF event. The imaginary part canbe updated when another transaction is correlated to the KF event of thespecific time and amount. In one embodiment, a table can have just oneimpedance value for the likelihood of any transaction occurring later.Thus, just one imaginary part could be stored for an entire table. Inanother embodiment, the imaginary parts could be different for eachmatrix element.

In an embodiment, a low impedance (e.g. a large negative imaginary part)for a matrix element means that there is a high probability that anothertransaction is going to occur, and a high impedance (e.g. high positivevalue) means that it is unlikely that another transaction is going tooccur, with zero being indeterminate. The implication of negative andpositive values can be swapped. In another embodiment, a high impedanceis provided by a low number (negative or positive), with larger numbersproviding low impedance, or vice versa. Certain future transactions canbe ignored (e.g. not counted) in determining impedance, for example, ifthe dollar amount is too low.

FIG. 7 is a flowchart of one method 700 for tracking an impedance of atransaction to future transactions by updating values using a backwardflow of events according to embodiments. In step 710, when a KF event isreceived, the real part of appropriate values in relevant key pairtables are increased. For example, each of the key pair tables that havethe transaction as the ending event are increased in the appropriatematrix element, with an elapsed time measured from the respectivestarting event KI.

In step 720, for each KI event of the relevant key-pair tables, each K0event to which KI is correlated as a final event is determined. Forexample, for each table in which KF is the final key, the specific KIevent to which KF was correlated is identified. Then, for eachidentified KI event, each K0 event to which the KI is correlated as afinal event is determined.

In step 730, the appropriate matrix elements of the <K0:KI> tables areadjusted. The appropriate matrix elements of specific tables can bedetermined using an elapsed time between the specific KI and K0 events.The individual matrix elements can be adjusted (e.g. decreased to obtaina reduced impedance) to reflect a higher likelihood that anothertransaction follows the KI event, since the KF event did indeed follow.If all of the matrix elements for a table have the same imaginary part,then the specific KI event does not need to be known, just the tablesthat have the key for an ending KI need to be known, which can bedetermined with filters operating on the final keys.

FIG. 8 is a flowchart of a second method 800 for tracking an impedanceof a transaction to future transactions by updating values using aforward flow of events according to embodiments. In step 810, a KF eventis identified, and each of the key pair tables that have KF as theending event are increased for the real part in the appropriate matrixelement, with a KI event being the starting event. In one aspect, KFmight not have just come in, but could be part of a whole collection ofevents being processed.

In step 820, for each KF event, each K2 final event to which KF iscorrelated as an initial event is determined. In step 830, the imaginarypart of the values from 810 is adjusted based on the number of K2 finalevents. Depending on the number of K2 transactions, the imaginary partof the appropriate matrix element can then be adjusted (e.g. increased,decreased, set, or reset). At this point, the imaginary part for justone matrix element (e.g. the matrix element from (a)) of tables for KFcould be determined. Or, all of the other matrix elements of the tablescould also be determined as well based on the value for the specificmatrix elements just determined. For example, all of the other matrixelements of a table can be updated to reflect that the K2 transactionoccurred. This can be done when all of the imaginary parts are the same,or if just one value is stored for an entire table.

In one embodiment, the default for the imaginary part can be set at zeroor some average value for a likelihood that a transaction occurs. Ifafter a certain amount of time, there are no transactions correlated toit, then the value might increase and continue to increase. Or thedefault could be set at a high impedance, and then lowered as moretransactions occur. In another embodiment, if the future transaction isfraudulent, then the complex part can also be changed to reflect ahigher impedance since a valid transaction does not occur. In anotherembodiment, if a decline occurs after a transaction then the impedanceis increased (e.g. the imaginary part is decreased by one), if anacceptance occurs after a transaction then the impedance is decreased(e.g. the imaginary part is increased by one).

Instead of or in addition to the above use of imaginary values forimpedance, greater impedance can also correspond to fraud. If a fraudtransaction K2 is found to correlate to a transaction K1, then the<KI:K1> matrix elements (or just a specific element) can have theimpedance increased. Thus, the impedance can reflect the profitabilityof the present transaction. For example, certain transactions happeningright after buying a concert ticket can be associated with fraud, whichis an example of where each matrix element may have its own complexpart.

In some embodiments, both real and imaginary parts of a matrix elementcan contribute to an overall value, which provides whether thetransaction is a good transaction with regards to likely occurring orbeing a transaction that leads to other transactions. Such transactionscan be encouraged. In other embodiments, values for the real or theimaginary components can be analyzed separately. In one implementation,when complex numbers are used, multiplications are performed bymultiplying the real parts by the real parts and imaginary parts by theimaginary parts (i.e. real*real and imaginary*imaginary).

A. Incentive to Encourage a Gateway Transaction

A transaction can be determined to be a gateway transaction that leadsto many other transactions, e.g. when a transaction has a low impedance.A gateway transaction can then be encouraged with an incentive. Forexample, a merchant can send a incentive for a transaction knowing thatthe transaction is correlated to other later transactions with thatmerchant. As another example, an incentive can be sent for a transactionat a first merchant that is known to correlate to later transactions ata second merchant. The cost of the incentive could be shared between thetwo merchants. However, the specific later transaction need not beknown.

FIG. 9 is a flowchart of a method 900 for providing an incentive to aconsumer to encourage a gateway transaction according to embodiments. Instep 910, data corresponding to transactions associated with theconsumer are received. In one embodiment, the transactions are onespreviously performed by the consumer.

In step 920, a first group of transactions are correlated to respectivetransactions of a first type. In one embodiment, a transaction of aparticular type corresponds to a specific key, as described above. Forexample, a transaction of the first type can be for a specific merchant,industry code, product code, etc. In one aspect, a correlatedtransaction of the first group occurs after a respective transaction ofthe first type.

In step 930, a computer system determines a likelihood of anytransaction occurring after a transaction of the first type initiated bythe consumer. The likelihood can be determined in various ways. In oneembodiment, determining the likelihood uses the number of correlatedtransactions. For example, the more correlated transactions can meanthat the likelihood of a future transaction is greater. In anotherexample, the number can be used in variety of ways, e.g., to increase ordecrease a value that is proportional to the number. Then the value canbe used to determine the likelihood.

In some embodiments, a value (e.g. imaginary part of the matrix element)can be increased when a correlated transaction occurs after atransaction of the first type. The value stored can be associated withan identifier of the first type of transaction (e.g. KF). In oneimplementation, the value can be decreased when a decline of acorrelated transaction occurs after a transaction of the first type. Inanother implementation, the value can be decreased when a correlatedtransaction does not occur after a transaction of the first type duringeach of one or more time periods.

In one embodiment, many values can be used, e.g., for different timesfor a <KI:KF> pair and for a different <KI:KF> pairs. In this manner,one can determine when is a best time to incentivize a transaction ofthe first type. In one aspect, just one imaginary part of a matrixelement can be used. In another aspect, an average or sum of all of theimaginary parts of the matrix elements of a particular table can be usedto determine whether any future transaction is likely. Also, theimaginary part can be aggregated over all KI correlated to a KF todetermine a total likelihood that a KF will provide more transactions.In other embodiments, one can integrate over all key pair tables with KFas an initial key, as opposed to using a pre-computed imaginary part ofa matrix element.

In step 940, an incentive for a future transaction of the first type issent to the consumer based on the likelihood being greater than athreshold. In one embodiment, time intervals between the correlatedtransactions and the transactions of the first type are tracked, e.g.,using the tables described above. In one implementation, one candetermine a number of correlated transactions having time intervalswithin a specified range, and the incentive can be sent when the numberis above a threshold. For example, when the number of transactionswithin the third, fourth, and fifth time ranges is above a threshold,the incentive can be sent. As an illustration, the third, fourth, andfifth time ranges can correspond to 30 minutes to four hours. In thismanner, the payoff of the future transactions being soon can be adetermining feature.

In another embodiment, each of the tables with KF as the finaltransaction can be used to determine exactly when to send an incentivefor the KF transaction and what the incentive might be. For example, thevalue (e.g. measuring impedance) can be associated with a particulartime of a transaction of the first type occurring, and the incentive issent at a time correlated with the particular time. In yet anotherembodiment, the correlated transactions can be correlated specificallyto a transaction of the first type occurring at the particular time.Thus, although a transaction of the first type might be more likely tooccur at a certain time, a first-type transaction occurring at adifferent time might be more likely to lead to future transactions.

B. Incentive to Encourage Transactions after a Dead End

A transaction can also be determined to be a dead end that does not leadto many later transactions. A high impedance can convey that thetransaction is a dead end as no further transactions occur very often.In such instances, it can be determined that incentives are needed toencourage other transactions (e.g. as they do not happen naturally).Thus, transactions can be sent after a dead end.

FIG. 10 is a flowchart of a method 900 for providing an incentive to aconsumer to encourage transactions after a dead end according toembodiments. In step 1010, data corresponding to transactions associatedwith the consumer are received. In one embodiment, the transactions areones previously performed by the consumer.

In step 1020, an amount of transactions that are correlated to a firsttransaction type and that occur after the first transaction type aredetermined. In various embodiments, the amount of transactions can bedetermined by methods described above. For example, the imaginary partof matrix element of key pair tables can be used to track the amount. Inanother embodiment, the key pair tables can be searched to identify theamount. The amount can be the number of correlated transactions or avalue derived from the number.

In step 1030, an incentive for any transaction based on the amount beingbelow a threshold is sent after a transaction of the first transactiontype occurs. In one embodiment, the incentive can be sent when theamount is below the threshold and if certain other criteria are met. Acriteria can be if an incentive (e.g. from incentive system 27) is for atransaction that the consumer is known to initiate or is likely toinitiate, e.g., based on other transaction patterns. In one aspect, theincentive can be for a second merchant near the merchant for thetransaction of the first type. In this manner, a consumer might belikely to use the incentive since the consumer is near or is often nearthe second merchant. The incentive can be sent as a message to a phone,which can have an advantage of reaching the consumer soon after the deadend transaction occurs and when the consumer's location can be easilyknown based on the location of the merchant.

In one embodiment, a criteria can be transaction patterns of otherconsumers (e.g. of affinity groups to which a consumer is similar),which can also be used to determine the incentive. For example, a deadend can be identified (e.g. by a computer system) for a consumer, andthen identify a similar affinity group that does not show this dead end.An analysis can be made as to why the dead end exists, and actions takento cause the dead end not to occur (e.g. sending a coupon,pre-authorization, or other incentive). For example, stores that the oneaffinity group does go to after the transaction can be identified, andcoupons for that store can be sent to the consumer for that store. Asanother example, one can identify stores geographically near a merchantthat is a dead end and send a coupon for a nearby store, evenpotentially for use within a short time period after a predicted visitto the dead end merchant. After seeing if a strategy works by sendingcoupons to a couple people in an affinity group, coupons can be sent tomore people in the affinity group (possibly including people justpartially in the affinity group).

In another embodiment, key pairs that should be correlated, but are not,can be used as a criteria of whether an incentive should be sent, andwhat the incentive should be. In one example, there may be equaltransactions at a gas station and at a donut store, both in the samegeographic location (e.g. same zip code). But, the transactions do notappear enough times to be correlated. The cause could be the consumer isusing cash or another form of payment not being tracked. For instance,if only 10% at each are with the card, then only 1% might showcorrelation, which may not be enough to normally identify a correlation.After additional analysis, a possible correlation may be identified, andan incentive can be sent. In one aspect, the incentive can be used totest whether a correlation actually exists. Such a test can also be donewhen a consumer does not show a pattern exhibited in an affinity groupto which the consumer belongs, or when two affinity groups haveoverlapping membership (but one does not show a pattern).

Any of the computer systems mentioned herein may utilize any suitablenumber of subsystems. Examples of such subsystems are shown in FIG. 11in computer apparatus 1100. In some embodiments, a computer systemincludes a single computer apparatus, where the subsystems can be thecomponents of the computer apparatus. In other embodiments, a computersystem can include multiple computer apparatuses, each being asubsystem, with internal components.

The subsystems shown in FIG. 11 are interconnected via a system bus1175. Additional subsystems such as a printer 1174, keyboard 1178, fixeddisk 1179, monitor 1176, which is coupled to display adapter 1182, andothers are shown. Peripherals and input/output (I/O) devices, whichcouple to I/O controller 1171, can be connected to the computer systemby any number of means known in the art, such as serial port 1177. Forexample, serial port 1177 or external interface 1181 can be used toconnect computer system 1100 to a wide area network such as theInternet, a mouse input device, or a scanner. The interconnection viasystem bus 1175 allows the central processor 1173 to communicate witheach subsystem and to control the execution of instructions from systemmemory 1172 or the fixed disk 1179, as well as the exchange ofinformation between subsystems. The system memory 1172 and/or the fixeddisk 1179 may embody a computer readable medium.

A computer system can include a plurality of the same components orsubsystems, e.g., connected together by external interface 1181. In someembodiments, computer systems, subsystem, or apparatuses can communicateover a network. In such instances, one computer can be considered aclient and another computer a server. A client and a server can eachinclude multiple systems, subsystems, or components, mentioned herein.

The specific details of particular embodiments may be combined in anysuitable manner without departing from the spirit and scope ofembodiments of the invention. However, other embodiments of theinvention may be directed to specific embodiments relating to eachindividual aspect, or specific combinations of these individual aspects.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using hardware and/orusing computer software in a modular or integrated manner. Based on thedisclosure and teachings provided herein, a person of ordinary skill inthe art will know and appreciate other ways and/or methods to implementthe present invention using hardware and a combination of hardware andsoftware

Any of the software components or functions described in thisapplication, may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C++ or Perl using, for example, conventional or object-orientedtechniques. The software code may be stored as a series of instructions,or commands on a computer readable medium for storage and/ortransmission, suitable media include random access memory (RAM), a readonly memory (ROM), a magnetic medium such as a hard-drive or a floppydisk, or an optical medium such as a compact disk (CD) or DVD (digitalversatile disk), flash memory, and the like. The computer readablemedium may be any combination of such storage or transmission devices.Any of the values mentioned herein can be output from one component toanother component and can be output to the user.

Such programs may also be encoded and transmitted using carrier signalsadapted for transmission via wired, optical, and/or wireless networksconforming to a variety of protocols, including the Internet. As such, acomputer readable medium according to an embodiment of the presentinvention may be created using a data signal encoded with such programs.Computer readable media encoded with the program code may be packagedwith a compatible device or provided separately from other devices(e.g., via Internet download). Any such computer readable medium mayreside on or within a single computer program product (e.g. a harddrive, a CD, or an entire computer system), and may be present on orwithin different computer program products within a system or network. Acomputer system may include a monitor, printer, or other suitabledisplay for providing any of the results mentioned herein to a user.

The above description of exemplary embodiments of the invention has beenpresented for the purposes of illustration and description. It is notintended to be exhaustive or to limit the invention to the precise formdescribed, and many modifications and variations are possible in lightof the teaching above. The embodiments were chosen and described inorder to best explain the principles of the invention and its practicalapplications to thereby enable others skilled in the art to best utilizethe invention in various embodiments and with various modifications asare suited to the particular use contemplated.

What is claimed is:
 1. A method of providing an incentive to a consumer, the method comprising: receiving data corresponding to previous transactions associated with the consumer, each of the previous transactions associated with one or more keys, and each of the one or more keys corresponding to a particular type of transaction; storing, in a table corresponding to an initial key and a final key, counts of a plurality of elapsed times between previous transactions associated with the initial key and previous transactions associated with the final key, each elapsed time of the plurality of elapsed times corresponding to an elapsed time between one transaction associated with the initial key and one transaction associated with the final key; determining, by a computer system, a likelihood for a future transaction at each future time of a plurality of future times, the future transaction being associated with the final key, the likelihood for the future transaction at each particular future time being determined based on a count of elapsed times in the table corresponding to the particular future time; predicting, by the computer system, a time window when the consumer is likely to initiate the future transaction using the likelihoods at the plurality of future times; and sending an incentive associated with the future transaction to the consumer such that the consumer receives the incentive at a time within the predicted time window.
 2. The method of claim 1, wherein the determining of the likelihood for the future transaction at each particular future time is further based on one or more counts of elapsed times corresponding to the particular future time in one or more additional tables, each of the one or more additional tables corresponding to the final key and a different initial key.
 3. The method of claim 1, wherein the predicting of the time window when the consumer is likely to initiate the future transaction is further based on a first threshold, wherein a duration of the time window is variable, a start of the time window based on a first likelihood at a first future time being above the first threshold and an end of the time window based on a second likelihood at a second future time being below the first threshold.
 4. The method of claim 3, wherein a start of the time window is at a specified amount of time relative to the first future time when the likelihood is above the first threshold.
 5. The method of claim 1, further comprising specifying specific values for categories associated with the future transaction, wherein the time window is when the consumer is likely to initiate the future transaction having the specified values, the categories including one or more of an account number, an amount of the transaction, a time and date, a type product or service, a merchant name or code, an industry code, a terminal field, and a geographic location.
 6. The method of claim 1, further comprising determining that the consumer is within an affinity group including one or more other consumers, wherein the time window when the consumer is likely to initiate the future transaction is based on likelihoods of the one or more other consumers initiating the future transaction.
 7. The method of claim 1, further comprising predicting a merchant at which the future transaction is to occur, wherein the incentive is for a first product that is available at the merchant, wherein the first product is a different product than a product predicted for the future transaction.
 8. The method of claim 1, wherein the consumer receives the incentive during the time window.
 9. The method of claim 1, wherein the incentive is sent at a predetermined time before the predicted time window.
 10. The method of claim 1, wherein the incentive is valid only during the predicted time window.
 11. The method of claim 1, further comprising: determining a cost associated with the sending of the incentive; and determining a benefit associated with the future transaction, wherein the sending of the incentive is based on the cost and the benefit.
 12. The method of claim 1, wherein sending of the incentive includes sending an electronic message to the consumer, wherein the electronic message is selected from the group consisting of an SMS message, an MMS message, and an e-mail.
 13. The method of claim 1, further comprising determining a peak time of the plurality of future times where a particular likelihood is a maximum, wherein the time window is correlated to the peak time.
 14. A method of providing an incentive to a consumer, the method comprising: receiving data corresponding to previous transactions associated with the consumer, each of the previous transactions being associated with one or more keys, and each of the one or more keys corresponding to a particular type of transaction; storing, in a table corresponding to an initial key and a final key, counts of a plurality of elapsed times between previous transactions associated with the initial key and previous transactions associated with the final key, each elapsed time of the plurality of elapsed times corresponding to an elapsed time between one transaction associated with the initial key and one transaction associated with the final key; determining, by a computer system, a likelihood of transactions associated with any key occurring within a time window after a first transaction associated with the initial key initiated by the consumer, the likelihood being determined based on a count of transactions associated with the table and having elapsed times corresponding to the time window; and sending an incentive associated with a future transaction to the consumer based on the likelihood being greater than a threshold.
 15. The method of claim 14, wherein the determining of the likelihood of transactions associated with any key occurring within the time window after the first transaction is further based one or more counts of transactions having elapsed times corresponding to the time window in one or more additional tables, each of the one or more additional tables corresponding to the initial key and a different final key.
 16. The method of claim 14, wherein the first transaction is with a first merchant, wherein the incentive is for a second merchant, and wherein transactions at the first merchant correlate to later transactions at the second merchant.
 17. A method of providing an incentive to a consumer, the method comprising: receiving data corresponding to previous transactions associated with the consumer, each of the previous transactions being associated with one or more keys, and each of the one or more keys corresponding to a particular type of transaction; storing, in a table corresponding to an initial key and a final key, counts of a plurality of elapsed times between previous transactions associated with the initial key and previous transactions associated with the final key, each elapsed time of the plurality of elapsed times corresponding to an elapsed time between one transaction associated with the initial key and one transaction associated with the final key; determining, by a computer system, a likelihood of transactions associated with any key occurring within a time window after a first transaction associated with the initial key initiated by the consumer, the likelihood being determined based on a count of transactions associated with the table and having elapsed times corresponding to the time window; and sending an incentive associated with a future transaction to the consumer based on the likelihood being less than a threshold.
 18. The method of claim 17, wherein the determining of the likelihood of transactions associated with any key occurring within the time window after the first transaction is further based one or more counts of transactions having elapsed times corresponding to the time window in one or more additional tables, each of the one or more additional tables corresponding to the initial key and a different final key.
 19. The method of claim 17, wherein the incentive is for a second merchant that is geographically near a first merchant involved in the first transaction.
 20. The method of claim 17, wherein the future transaction is selected based on transactions conducted by a group of consumers within an affinity group including the consumer that occur after transactions associated with the initial key.
 21. A computer system for providing an incentive to a consumer, the computer system comprising: a processor; and a non-transitory computer-readable storage medium comprising instructions executable by the processor for implementing a method comprising: receiving data corresponding to previous transactions associated with the consumer, each of the previous transactions associated with one or more keys, and each of the one or more keys corresponding to a particular type of transaction; storing, in a table corresponding to an initial key and a final key, counts of a plurality of elapsed times between previous transactions associated with the initial key and previous transactions associated with the final key, each elapsed time of the plurality of elapsed times corresponding to an elapsed time between one transaction associated with the initial key and one transaction associated with the final key; determining a likelihood for a future transaction at each future time of a plurality of future times, the future transaction being associated with the final key, the likelihood for the future transaction at each particular future time being determined based on a count of elapsed times in the table corresponding to the particular future time; predicting a time window when the consumer is likely to initiate the future transaction using the likelihoods at the plurality of future times; and sending an incentive associated with the future transaction to the consumer such that the consumer receives the incentive at a time within the predicted time window.
 22. The computer system of claim 21, wherein the determining of the likelihood for the future transaction at each particular future time is further based on one or more counts of elapsed times corresponding to the particular future time in one or more additional tables, each of the one or more additional tables corresponding to the final key and a different initial key.
 23. The computer system of claim 21, wherein the predicting of the time window when the consumer is likely to initiate the future transaction is further based on a first threshold, wherein a duration of the time window is variable, a start of the time window based on a first likelihood at a first future time being above the first threshold and an end of the time window based on a second likelihood at a second future time being below the first threshold.
 24. The computer system of claim 23, wherein a start of the time window is at a specified amount of time relative to the first future time when the likelihood is above the first threshold.
 25. The computer system of claim 21, wherein the method further comprises specifying specific values for categories associated with the future transaction, wherein the time window is when the consumer is likely to initiate the future transaction having the specified values, the categories including one or more of an account number, an amount of the transaction, a time and date, a type product or service, a merchant name or code, an industry code, a terminal field, and a geographic location.
 26. The computer system of claim 21, wherein the method further comprises determining that the consumer is within an affinity group including one or more other consumers, wherein the time window when the consumer is likely to initiate the future transaction is based on likelihoods of the one or more other consumers initiating the future transaction.
 27. The computer system of claim 21, wherein the method further comprises predicting a merchant at which the future transaction is to occur, wherein the incentive is for a first product that is available at the merchant, wherein the first product is a different product than a product predicted for the future transaction.
 28. The computer system of claim 21, wherein the consumer receives the incentive during the time window.
 29. The computer system of claim 21, wherein the incentive is sent at a predetermined time before the predicted time window.
 30. The computer system of claim 21, wherein the incentive is valid only during the predicted time window.
 31. The computer system of claim 21, wherein the method further comprises: determining a cost associated with the sending of the incentive; and determining a benefit associated with the future transaction, wherein the sending of the incentive is based on the cost and the benefit.
 32. The computer system of claim 21, wherein sending of the incentive includes sending an electronic message to the consumer, wherein the electronic message is selected from the group consisting of an SMS message, an MMS message, and an e-mail.
 33. The computer system of claim 21, wherein the method further comprises determining a peak time of the plurality of future times where a particular likelihood is a maximum, wherein the time window is correlated to the peak time.
 34. A computer system for providing an incentive to a consumer, the computer system comprising: a processor; and a non-transitory computer-readable storage medium comprising instructions executable by the processor for implementing a method comprising: receiving data corresponding to previous transactions associated with the consumer, each of the previous transactions being associated with one or more keys, and each of the one or more keys corresponding to a particular type of transaction; storing, in a table corresponding to an initial key and a final key, counts of a plurality of elapsed times between previous transactions associated with the initial key and previous transactions associated with the final key, each elapsed time of the plurality of elapsed times corresponding to an elapsed time between one transaction associated with the initial key and one transaction associated with the final key; determining, by a computer system, a likelihood of transactions associated with any key occurring within a time window after a first transaction associated with the initial key initiated by the consumer, the likelihood being determined based on a count of transactions associated with the table and having elapsed times corresponding to the time window; and sending an incentive associated with a future transaction to the consumer based on the likelihood being greater than a threshold.
 35. The computer system of claim 34, wherein the determining of the likelihood of transactions associated with any key occurring within the time window after the first transaction is further based one or more counts of transactions having elapsed times corresponding to the time window in one or more additional tables, each of the one or more additional tables corresponding to the initial key and a different final key.
 36. The computer system of claim 34, wherein the first transaction is with a first merchant, wherein the incentive is for a second merchant, and wherein transactions at the first merchant correlate to later transactions at the second merchant.
 37. A computer system for providing an incentive to a consumer, the computer system comprising: a processor; and a non-transitory computer-readable storage medium comprising instructions executable by the processor for implementing a method comprising: receiving data corresponding to previous transactions associated with the consumer, each of the previous transactions being associated with one or more keys, and each of the one or more keys corresponding to a particular type of transaction; storing, in a table corresponding to an initial key and a final key, counts of a plurality of elapsed times between previous transactions associated with the initial key and previous transactions associated with the final key, each elapsed time of the plurality of elapsed times corresponding to an elapsed time between one transaction associated with the initial key and one transaction associated with the final key; determining, by a computer system, a likelihood of transactions associated with any key occurring within a time window after a first transaction associated with the initial key initiated by the consumer, the likelihood being determined based on a count of transactions associated with the table and having elapsed times corresponding to the time window; and sending an incentive associated with a future transaction to the consumer based on the likelihood being less than a threshold.
 38. The computer system of claim 37, wherein the determining of the likelihood of transactions associated with any key occurring within the time window after the first transaction is further based one or more counts of transactions having elapsed times corresponding to the time window in one or more additional tables, each of the one or more additional tables corresponding to the initial key and a different final key.
 39. The computer system of claim 37, wherein the incentive is for a second merchant that is geographically near a first merchant involved in the first transaction.
 40. The computer system of claim 37, wherein the future transaction is selected based on transactions conducted by a group of consumers within an affinity group including the consumer that occur after transactions associated with the initial key. 